Internet AAA systems provide Authentication, Authorisation and Accounting (AAA) for Internet Service Providers (ISPs) so that End Nodes (ENs) and/or their users can be identified, and given access to a controlled set of service capabilities for which consumption can then be measured. End nodes may be, e.g., fixed devices such as desk top PCs or mobile devices such as PDAs and/or portable computers which may connect to a network via a wireless communications link. End nodes and their corresponding users are normally identified by a network access identifier (NAI). While in their home domain, Internet service is normally provided to an end node from a home ISP which uses a first, e.g., home, AAA system. The AAA system typically includes a AAA server that is used to provide AAA functionality.
The Internet AAA architecture has a roaming capability whereby a user outside his home domain can obtain service from a second, e.g., foreign, ISP who has a business relationship either with the home ISP or a third party broker/settlement system. The user is authenticated and authorized by the home ISP, so that the foreign ISP can generate accounting records and receive payment for the service provided to the roaming user. Roaming is facilitated by the user providing its Network Access Identifier (NAI), e.g., username@realm such as john_smith@home_ISP.com, to the foreign ISP. The second ISP uses the NAI realm for AAA routing, to identify the target AAA system of the home ISP and to then proxy the AAA request for the user authentication to the identified AAA system, potentially via a third AAA system corresponding to a broker. This AAA proxying relies on security associations that are in place between the home and foreign ISPs, or between the third settlement service and both the home and foreign ISPs, to secure the AAA transactions that flow between the home and foreign ISPs. For the purpose of authentication with the home AAA server, the user and its home AAA server share a secret that is used in combination with its NAI. The shared secret may be stored in the home AAA server and the user device and is accessed, as needed, for use in performing authentication and/or encryption/decryption functions.
Since the foreign AAA system has no knowledge of the user's NAI, it simply passes the Access_Request to the home AAA and receives back an access response (accept/reject). If the access response is accept, e.g., an Access_Accept, the response constitutes a commitment by the home AAA system that the charges incurred by the user will be met. Specifically, the user normally does not at any time have a user account created in the database of the foreign AAA (AAAF) and there is no need for the user and AAAF to have any form of shared secret. This is because the user requires only a single shot authorization provided by the home AAA system and is subsequently granted connectivity. This model however is insufficient if various additional services are to be consumed in the foreign domain by the user for which either unilateral or mutual authentication with the foreign domain is required. This is because in the described system a shared secret is only available in the home AAA system (AAAH) and is therefore unavailable in the AAAF, i.e. there is no shared secret present between the AAAF and the user device. For example, if link layer encryption keys need to be derived for security/privacy reasons then, with the existing model, these keys can only be derived by the home AAA system although the communication links used belong to the foreign AAA system where the user happens to be. Other security associations between the user and the foreign network may also be needed such as security associations with application specific servers like Session signalling servers, mobility agents, paging agents etc. The inability of the AAAF to perform authentication/authorization is limiting and can interfere with the ability to provide service to a node visiting a foreign domain.
We note here that if the foreign (or home) wireless network were to use a public key infrastructure for its security needs, then there would be no need for a shared secret between the user and the AAAF: instead, a certification authority would vouch for the public keys of the user and the AAAF. It is well known in the art that the public key system is computationally burdensome for power-limited wireless devices, and thus it is rarely employed in real-life wireless networks.
Based upon the above discussion, it is clear that a need exists for a better AAA system and method to satisfy the security needs of wireless networks, particularly concerning how security is handled between home and foreign domains during roaming.